Hi,
I'm not very keen to accept either of these changes. I originally considered adding the 'DELETE' security to removing an alias, but decided against it because it is easy to undo. If you accidentally delete an alias you can just add it back again using the 'add alias' menu item.

For the compacting aliases I dont want to do that because one of the nice features of aliases is that you can have a single alias against many indicies. This change would make this less obvious, also I have some future plans to make it even easier to manage aliases from this interface, which require the table layout.

I'd be happy to consider a patch which enabled hide/show of the alias rows though.

-B

For us, deleting an alias, even if for just a minute means the loss of data. We have real-time services that are continuously hitting our indexes and losing any amount of data is not acceptable. Better safe than sorry.

As for the table layout, I hadn't considered aliases for multiple indexes, so I see why you initially went with a table row per alias. One of our elasticsearch instances has over 50 indexes and at some point, every single one of them may have at least 1 alias. Having 50 table rows of aliases between the index names and the node information would make the interface hard to use. Not to mention that with the amount of scrolling we have for the list of indexes, any benefit of having the same alias name in the same table row would be lost because you wouldn't be able to easily see all the indexes at once anyway. I'm not sure hiding them helps really because the aliases are important information.

I realize our usage of elasticsearch may not be typical, but I wanted to give you my reasons behind why these changes are important to us ... the tool is really helpful though, we've gotten a lot of use out of it!

Thanks,
Justin

Hi Justin,
Thanks for the response. I actually think your usage of elasticsearch is quite typical (eg 50 indicies or more) and elasticsearch-head does not currently handle this case very well. I'm trying to think of some ways of improving the view in this scenario (for example changing the orientation of the cluster so nodes are across the top and indicies go down. Perhaps you could resubmit your patch but allow the user to control the display if aliases.

Eg have a drop down in the menu bar with the options 'Full', 'Compact', 'None', which would toggle the alias row between the current view, your view and a view with aliases hidden? If you don't feel comfortable with that, please leave this pull request open, and I will try to find time to update it.

This pull is awesome, please reconsider accepting it.

Changing the orientation would be nice. Also having an input field where one can easily filter the indices is an option to get a better and faster understanding for several indices.